---
theme: gaia
_class: lead
paginate: true
backgroundColor: #fff
marp: true
math: mathjax
---

<style>
img[alt~="center"] {
  display: block;
  margin: 0 auto;
}
code {
    background: #000;
}
pre {
    background: #000;
}
</style>

# Автоматизация разработки и эксплуатации ПО

<style scoped>
h1 {
    font-size: 1.5rem;
}
h2 {
    font-size: 1rem;
}
</style>

![bg left:40% 80%](../images/iu5edu_logo.jpg)

## Наблюдаемость системы

**Аладин** Дмитрий Владимирович

[iu5edu.ru/wiki/devops/](https://iu5edu.ru/wiki/devops/)

---

# План

<style scoped>
h1 {
    font-size: 1rem;
}
li {
    font-size: 0.8rem;
}
</style>

1. Понятие наблюдаемость системы. Уровни наблюдаемости.
2. Аудит.
3. Логирование. Уровни логирования. Сценарии использования логирования.
4. Метрики. Методологии сбора метрик.
5. Мониторинг. Виды мониторинга.
6. Распределенная трассировка.
7. Оповещения.
8. Средства мониторинга: Nagios, Zabbix, VictoriaMetrics.
9. Средства логирования. ELK-стек и его альтернативы. Grafana Loki. Monq.
10. OpenTelemetry.

---

# Мысленный эксперимент

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Предположим, что вы создали прекрасную систему с восхитительной бизнес-логикой. Архитектура вашей системы выглядит безупречно:

![height:450px center](./images/web-app-architecutre.jpg)

---

<style scoped>
p {
    font-size: 1rem;
}
p {
    font-size: 0.85rem;
}
li {
    font-size: 0.8rem;
}
</style>

![bg right:50% 170%](images/one-punch-man.jpg)

Благодаря тому, что на данный момент узнали на занятиях АРЭ ПО, вы уже можете:

- **Упаковать** компоненты вашей системы в **контейнеры Docker**;
- **Настроить CI/CD** для вашей системы;
- **Обеспечить отказоустойчивость кластера Docker** вашей системы;
- **Воспользоваться** всеми преимуществами **Kubernetes**.

---

Иными словами, у вас в проекте есть:

- Сервера под управлением некоторой ОС
- Сеть и сетевое оборудование
- Вспомогательное (DNS, DHCP, Backup, ...)
- Continuous integration / Continuous delivery (CI/CD)
- Load balancing (LB), fault-tolerance (FT), high availability (HA)
- Supervision, orchestration, auto-scaling, service discovery

---

![bg left:40% 120%](images/money_mem.jpg)

Вы протестировали вашу систему на этапе CI, развернули вашу систему на этапе CD, дали пресс-релиз о запуске и приготовились зарабатывать все деньги мира благодаря вашей системе.

---

![bg right:50% 170%](images/surprised-face-mem.jpg)

<style scoped>
p {
    font-size: 0.9rem;
}
li {
    font-size: 0.9rem;
}
</style>

Но что-то пошло не так:

- выручка от вашей системы испытывает **отрицательный рост**, как бы этого хотелось;
- ваш кошелек **опустошается** из-за содержания вашей инфраструктуры;
- клиенты на форумах **жалуются** на то, что система вообще "не работает, лагает, раньше было лучше".

---

Вы внимательно присмотрелись к практикам DevOps и поняли, что вы еще не касались темы "Мониторинг":

![height:450px center](./images/devops-pipeline.png)

---

<style scoped>
p {
    font-size: 0.9rem;
}
li {
    font-size: 0.9rem;
}
</style>

![bg left:50% 200%](images/anya_mem.jpg)

Из единственных средств мониторинга у вас сейчас:

- Почитать **логи контейнера Docker** и попытаться понять что вообще происходит;
- **Реакция клиентов** на ваши новые "фитчи".

Наверное, это не все практики DevOps, которые можно было применить для вашей изумительной системы...

---

<style scoped>
p {
    font-size: 0.9rem;
}
</style>

![bg right:50% 100%](images/telemetry_mem.jpg)

При запуске приложения необходимо **знать**, насколько хорошо работает приложение, и **обнаруживать** потенциальные проблемы, прежде чем они становятся более крупными.

Обычно разработчики делают это, делая приложение выдавать данные **телеметрии**, такие как **журналы** или **метрики**, а затем отслеживать и анализировать эти данные.

---

Иными словами, у вас в проекте должно быть:

- Сервера под управлением некоторой ОС
- Сеть и сетевое оборудование
- Вспомогательное (DNS, DHCP, Backup, ...)
- Continuous integration / Continuous delivery (CI/CD)
- Load balancing (LB), fault-tolerance (FT), high availability (HA)
- Supervision, orchestration, auto-scaling, service discovery
- **Logging & monitoring & tracing**
- **Infrastructure automation & infrastructure as code (IaC)** (в будущих лекциях)

---

Архитектура современных систем может сложной:

![height:450px center](./images/decentralizaciya.png)

Поэтому сбор телеметрии может быть проблематичным!

---

# Что такое наблюдаемость

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 0.9rem;
}
</style>

**[Наблюдаемость](https://learn.microsoft.com/ru-ru/dotnet/core/diagnostics/observability-with-otel)** в контексте распределенной системы — это возможность **отслеживать** и **анализировать** данные **телеметрии** о состоянии каждого компонента, **иметь возможность наблюдать** за изменениями производительности и **диагностировать** причины возникновения этих изменений.

В отличие от **отладки**, которая является инвазивной (способной проникать) и **может повлиять на работу приложения**, **наблюдаемость** предназначена для прозрачной основной операции и имеет **небольшое влияние на производительность**, которое может быть использовано непрерывно.

**Телеметрия** - данные, собранных средствами наблюдаемости.

---

# 3 столпа наблюдаемости

- **Логи** (aka *журналы*), которые записывают отдельные операции, такие как входящий запрос, сбой в определенном компоненте или размещение заказа.
- **Метрики**, которые измеряют счетчики и датчики, такие как количество завершенных запросов, активные запросы и задержки запроса.
- **Распределенная трассировка**, которая отслеживает запросы и действия между компонентами в распределенной системе, чтобы увидеть, где время тратится и отслеживает конкретные сбои.

---

# Преимущества наблюдения

<style scoped>
h1 {
    font-size: 1.1rem;
}
p {
    font-size: 0.9rem;
}
li {
    font-size: 0.9rem;
}
</style>

![bg right:37% 105%](images/observation_advantages_mem.jpg)

Наблюдение за системой даёт ряд [преимуществ](https://habr.com/ru/companies/ruvds/articles/727072/):

1. Ускорение разрешения инцидентов;
2. Повышение быстродействия системы;
3. Эффективное планирование ресурсопотребления;
4. Повышение эффективности разработки;
5. Более эффективное сотрудничество;
6. Повышение надёжности системы.

---

# Преимущества наблюдения в деталях

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

1. **Отображает текущее и предыдущее состояние системы**. Например, так можно узнать, что ночью нагрузка системы достигала 70%, а потому, возможно, нужно добавить новый инстанс.
2. **Демонстрирует, как пользователи пользуются системой**. Например, какие действия пользователя популярны, какие кнопки чаще всего нажимают пользователи.
3. **Подсвечивает, где и как уменьшить затраты на работу системы**. Предположим, по телеметрии видно, что из четырех инстансов реально работает только один — и тот на 20%. В таком случае можно отказаться от двух лишних (базовый минимум – два инстанса).
4. **Оптимизирует CI/CD-пайплайны**. Например, если один из степов билда или деплой занимает много времени, то с телеметрией можно увидеть, что именно занимает так много времени и когда эти проблемы начались.

---

# Уровни наблюдаемости

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

![bg left:40% 100%](images/levels_of_observability.svg)

Наблюдаемость можно рассмотреть [в разрезе уровней](https://agilemindset.ru/observability-как-наблюдать-за-системой/), каждый базируется на предыдущем:

- Наверху **оповещения** как результат выполнения аналитической функции от метрик, собираемых в процессе мониторинга на базе логов и иных показателей.
- Внизу находится **аудит**, позволяющий отследить изменения в системе, помогает и в выявлении причин проблем.

---

# Аудит

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

[**Аудит**](https://agilemindset.ru/observability-как-наблюдать-за-системой/) с точки зрения наблюдаемости - возможность локализовать изменения, которые могли привести к проблемам. Это помогают нам сделать **контроль версий** и **системы контроля версий**.

![height:400px center](./images/audit.png)

---

# 1-ый столп наблюдения: логирование

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- **Автоматические** – генерируются с помощью фреймворка или сервиса (CI/CD в GitLab). С помощью этих данных можно логировать, например, какой реквест пришел и получился, что было внутри реквеста. С автоматическими логами ничего не нужно делать для сбора данных, что удобно для рутинных задач.
- **Мануальные** – нужно запускать вручную. Не так просто, как с автоматическими, но это оправданно при логовании важных частей системы. Это обычно нагруженные или нацеленные на бизнес-задачи процессы. Скажем, в образовательной системе будет значимой проблемой потерять тесты студентов за определенный период.

**Обычно логировать все данные ненужно**. Оцените систему, найдите наиболее уязвимые и ценные части системы. Скорее всего, там нужно добавить логов.

---

<style scoped>
p {
    font-size: 0.9rem;
}
</style>

Данные в логах могут включать информационные сообщения, предупреждения, ошибки и прочую информацию, обычно сохраняемую в файле журнала или базе данных:

![height:500px center](./images/log_stack_example.png)

---

# Сопутствующие цели логирования

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 1rem;
}
li {
    font-size: 0.8rem;
}
</style>

- **Аудит**: с помощью логирования можно отслеживать пользовательскую активность в системе или приложении, получая информацию о том, кто, к каким данным и когда обращался.
- **Соответствие требованиям**: логирование можно использовать для выполнения нормативных требований или требований совместимости, таких как [HIPAA](https://ru.wikipedia.org/wiki/HIPAA) (акт о мобильности и подотчётности медицинского страхования) или [PCI-DSS](https://ru.wikipedia.org/wiki/PCI_DSS) (стандарт безопасности данных платёжных карт), которые предписывают хранение и анализ определённых типов данных.
- **Мониторинг производительности**: с помощью логирования можно отслеживать метрики производительности, такие как время отклика или использование ресурсов, используя их для оптимизации быстродействия системы.

---

# [Уровни логирования](https://www.tune-it.ru/web/egoshin/blog/-/blogs/raspredelennoe-logirovanie-ili-kak-debazit-kogda-mikroservisy)

<style scoped>
h1 {
    font-size: 1.1rem;
}
p {
    font-size: 0.9rem;
}
li {
    font-size: 0.9rem;
}
</style>

- `debug` - отладочная информация, которая чаще всего используется при тестировании системы;
- `info` - средней важности информация, чаще всего регистрирующая факт свершения некоторого события;
- `warn` - предупреждения о потенциальных ошибках конфигурации или приближении крупных проблем;
- `error` - ошибка свершилась, пора с ней разбираться.

Крайне малое совершенно неинформативных логов, либо чрезвыйная их избыточность, которая затруднит анализ логов даже с использованием специальных инструментов!

---

# Сценарии использования логов

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

1. Самый очевидный сценарий - у пользователя произошла ошибка или не дай бог **упал какой-то сервис** и нужно быстро разобраться, что же пошло не так.
2. **Наступление событий**. Здесь важно сделать акцент на том, что такие события могут быть вызвана как действием пользователя, так и результатом асинхронных задач. Однако важно, чтобы частота отслеживаемых событий не была большой.
3. **Отслеживание пользовательской активности**. Отличие этого случая от второго в том, что при отслеживании активности подразумевается, что частота совершаемых действий может быть достаточно большой.
4. **Отлаживание функциональности**. Вот тут то пригодятся наиболее подробные логи. Однако подобным лучше заниматься на тестовых стендах, где интенсивность логов не такая высокая.

---

# Примеры использования сценариев логирования

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

*Случай 1. Ошибки*:

- В случае задуманной ошибки: в `debug`. Пример: ошибка 404.
- В случае неожиданной ошибки: подробный лог в `error` . Пример: ошибка записи в базу данных. Берем объект, с которым возникла ошибка и целиком его логируем вместе со всеми полями (исключая совсем приватные), а также логируем данные из запроса пользователя (контекст).

*Случай 2. Наступление событий*:

Мы пытаемся понять причину возникнувшей ошибки, нам может быть недостаточно контекста и мы захотим понять историю действий пользователя или даже обработки конкретного запроса (см. далее распределенную трассировку).

---

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

*Случай 3. Отслеживание пользовательской активности*:

Фиксация действий пользователя в наиболее сложных сценариях или наиболее критичных для бизнеса. То есть принципиальное отличие от случая 2 в том, что отслеживание пользовательской активности позволяет разработчику понять, что делал пользователь до наступления ошибки.

*Случай 4. Отладка*:

Отладочные логи, к сожалению, неизбежно раздувают размер файлов с исходным кодом, так как их приходится писать достаточно много. Плюс на это тратиться драгоценное время, однако использование отладочных логов позволяет сэкономить время при внесении изменений в код, продиктованных как рефакторингом, так и изменением хотелок бизнеса.

Отладочные логи можно включать на конкретные компоненты системы.

---

# Как выполнять логирование (1)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.85rem;
}
li {
    font-size: 0.85rem;
}
</style>

1. **Логирование приложений**: многие языки программирования и фреймворки предоставляют встроенную поддержку логирования приложения, позволяя разработчикам логировать сообщения на разных уровнях важности (например, информационные, предупреждения, ошибки), распределяя их по разным категориям.
2. **Системное логирование**: операционные системы и сетевые устройства зачастую предоставляют свои механизмы логирования для перехвата системных событий, таких как авторизация, ошибки и использование ресурсов.
3. **Логирование с помощью агентов**: многие инструменты логирования и сервисы предоставляют агентов или библиотеки, которые можно установить в системы или приложения для сбора данных логов.

---

# Как выполнять логирование (2)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.85rem;
}
li {
    font-size: 0.85rem;
}
</style>

4. **Контейнерное логирование**: контейнеризованные приложения, выполняющиеся на таких платформах, как Docker или Kubernetes, генерируют данные логов, специфичные для среды контейнера.
5. **Облачное логирование**: многие облачные платформы и сервисы предоставляют механизмы логирования для перехвата событий и данных, связанных с облачными ресурсами, такими как виртуальные машины, базы данных и сервисы приложений.

---

# 2-ой столп наблюдения: метрики

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
li {
    font-size: 1rem;
}
</style>

- **Автоматические** – метрики, которые предоставляет система. Например, в Windows можно увидеть показатели нагрузки на CPU, количество реквестов и т.д. В большинстве облачных платформ вы сможете обнаружить метрику на станицах управления виртуальными машинами. Там можно найти количество данных, которые поступают в систему или исходят из нее.
- **Мануальные** – можете добавлять их сами. Например, когда нужно видеть актуальное количество подписок на сервис. Это можно реализовать через логи, но их нужно сосчитать. С метриками все смотрится наглядно и понятно для клиента.

---

# Примеры метрик

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
li {
    font-size: 1rem;
}
</style>

- **Метрики производительности**, такие как время отклика, пропускная способность и частота ошибок.
- **Метрики потребления ресурсов**, такие как использование ЦПУ, памяти и дисковой системы ввода-вывода.
- **Бизнес-метрики**, такие как доход, вовлечённость пользователей и удовлетворённость клиентов.

![height:80px center](./images/uptime_mem.jpg)

---

# Примеры бизнес-метрик

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- **[Использование фичей](https://agilemindset.ru/observability-как-наблюдать-за-системой/)** — интенсивность использования фичи клиентами. Помогает определить, стоит ли вкладываться в развитие фичи в том виде, в котором она сейчас представлена.
- **Время выполнения задачи клиентом** — насколько быстро клиент может зарегистрироваться в системе, насколько быстро может оформить покупку, насколько быстро может подготовить отчет, в общем, — насколько быстро клиент достигает результата.
- Сколько клиентов и на каком этапе перестают пользоваться продуктом с контекстом состояния продукта (например, каким было **время отклика** в этот момент).
- Бизнес-метрики в разрезе различных вариантов реализации при **[A/B-тестировании](https://ru.wikipedia.org/wiki/A/B-тестирование)** (контрольная группа элементов сравнивается с набором тестовых групп).

---

# Методологии сбора метрик

<style scoped>
h1 {
    font-size: 1.1rem;
}
p {
    font-size: 0.9rem;
}
li {
    font-size: 0.9rem;
}
</style>

- [**Google SRE**](https://sre.google/books/): *Latency* (время, необходимое вашей службе для выполнения запроса.), *Traffic* ( насколько велик спрос на ваши услуги), *Errors* (частота сбоев в работе вашего сервиса), *Saturation* (насыщенность — показатель того, насколько близки к полному использованию ресурсы сервис).
- [**Метод USE**](https://www.brendangregg.com/usemethod.html): *Utilization* (процент времени, когда выполнялась полезная работа), *Saturation*, *Errors*
- [**Метод RED**](https://www.weave.works/blog/the-red-method-key-metrics-for-microservices-architecture/): *Rate* ( количество запросов в секунду, которые обслуживают ваши сервисы), *Errors*, *Duration* (распределение количества времени, затрачиваемого на каждый запрос).

---

# Как собирать метрики (1)

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
li {
    font-size: 1rem;
}
</style>

- **Реализация**: метрики можно собирать путём реализации кода внутри приложения или системы. Это подразумевает добавление кода для перехвата определённых метрик, таких как время отклика или частота ошибок, и отправки их в систему мониторинга.
- **Метрики на основе логов**: метрики также можно извлекать из данных журналов, сгенерированных приложениями или системами. Этот подход включает извлечение метрик из файлов журналов, например количеств определённых типов событий или ошибок, и их отправку в систему мониторинга.

---

# Как собирать метрики (2)

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 0.9rem;
}
li {
    font-size: 1rem;
}
</style>

- **Системные метрики**: операционные системы и компоненты инфраструктуры, такие как серверы, сети и базы данных, обычно отражают встроенные метрики, которые можно собирать и мониторить с помощью инструментов системы.
- **Сторонние сервисы**: многие облачные сервисы предоставляют встроенные метрики, к которым можно обращаться и мониторить через API или веб-интерфейсы.

Какой бы метод ни использовался, важно, чтобы **метрики собирались** с подходящей частотой и точностью, и **сохранялись** при этом **удобным для запроса и анализа образом**.

---

# Мониторинг

<style scoped>
h1 {
    font-size: 1.1rem;
}
p {
    font-size: 0.8rem;
}
</style>

![bg left:50% 90%](images/monitoring_mem.jpg)

**Мониторинг системы** – это процесс наблюдения и сбора данных о производительности, поведении и состоянии компьютерной системы либо приложения.

**Цель мониторинга** – обеспечение оптимальной работы системы и приложений, а также определение и разрешение проблем по мере их возникновения.

---

# Пример данных, собираемым в ходе системного мониторинга

<style scoped>
h1 {
    font-size: 1.1rem;
}
p {
    font-size: 0.9rem;
}
li {
    font-size: 0.9rem;
}
</style>

- **Метрики производительности**: определение времени отклика, пропускной способности и частоты ошибок помогает понять, насколько хорошо работает система или приложение.
- **Метрики использования ресурсов**: определение использования ЦПУ, памяти и дискового ввода-вывода помогает понять, каким образом задействуются ресурсы системой или приложением.
- **Данные журналов**: журналы системы или приложений помогают разобраться в их поведении, а также могут использоваться для исправления проблем и выявления ошибок.

---

# Виды мониторинга

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
li {
    font-size: 1rem;
}
</style>

![bg left:40% 90%](images/types_of_monitoring.svg)

- top, atop, iostat, ...
- **Push** metrics (Zabbix, Carbon, ...)
- **Pull** metrics (Prometheus, VM)


---

# Как проводить мониторинг (1)

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
li {
    font-size: 1rem;
}
</style>

- **Сбор данных**: инструменты мониторинга системы собирают данные из различных источников, таких как журналы, счётчики производительности или API. Данные можно собирать в реальном времени либо в пакетах, что зависит от требований программы мониторинга.
- **Хранение данных**: после сбора данные мониторинга помещаются в хранилище, такое как база данных временных рядов или агрегатор логов. Обычно данные сохраняются в структурированном формате, что позволяет их эффективно запрашивать и анализировать.

---

# Как проводить мониторинг (2)

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
li {
    font-size: 1rem;
}
</style>

- **Анализ данных**: инструменты мониторинга анализируют собранные данные с целью выявления тенденций, паттернов и проблем. Этот анализ можно выполнять с помощью различных техник, таких как статистический анализ, машинное обучение или оповещения на основе порогов.
- **Отчёты и визуализация**: результаты анализа обычно представляются в виде отчётов, сводных таблиц или оповещений. Эти данные помогают понять производительность и поведение системы, а также выявить проблемы до того, как они станут критическими.

---

# 3-ий столп наблюдения: распределенная трассировка

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
</style>

**[Распределенная трассировка](https://habr.com/ru/companies/ruvds/articles/727072/)** – это техника мониторинга и отладки крупных распределённых систем. Она подразумевает реализацию кода для генерации трейсов, представляющих собой записи активности отдельных запросов по мере их прохождения через систему. Впоследствии эти трейсы агрегируются для предоставления подробной картины обработки запросов различными компонентами системы.

---

# Как выполнять распределенную трассировку (1)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

1. Работает эта техника путём генерации и распространения контекста трейса (**trace context**) по распределённой системе.
2. Когда сервис получает запрос, он генерирует контекст трейса, включающий уникальный **trace ID** и **span ID**.

![height:350px center](./images/distributed_tracing_example.png)

---

# Как выполнять распределенную трассировку (2)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

3. **Trace ID** используется для определения самого запроса, а **span ID** определяет конкретную операцию или активность в рамках этого запроса.
4. Когда запрос обрабатывается сервисом, контекст трейса передаётся другим сервисам, задействованным в этой обработке.

![height:350px center](./images/distributed_tracing_example.png)

---

# Как выполнять распределенную трассировку (3)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

5. Каждый сервис в процессе обработки генерирует новые спаны и добавляет их в контекст трейса. Так создаётся цепочка спанов, представляющая весь путь запроса через систему.
6. Полный контекст трейса возвращается клиенту либо сохраняется в бэкенде трассировки в конце обработки запроса.

![height:350px center](./images/distributed_tracing_example.png)

---

# Как выполнять распределенную трассировку (4)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

7. Затем контекст трейса можно визуализировать и проанализировать для лучшего понимания производительности и поведения системы.

![height:350px center](./images/distributed_tracing_example.png)

---

# Оповещения

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

**Оповещения** – это способ автоматического уведомления причастных сторон о возникновении в системе или приложении конкретного события или состояния.

**Цель оповещений** в том, чтобы быстро выявлять и реагировать на проблемы на ранних стадиях.

![bg left:60% 170%](./images/notifications_mem.jpg)

---

# Примеры условий отправки оповещений

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- **Использование ресурсов**: когда система или приложение превышает заданный порог использования процессора, памяти или прочих метрик ресурсов.
- **Сообщения ошибок**: когда в журнале приложения или системы обнаруживаются сообщения об ошибках, указывающие на проблему.
- **Метрики производительности**: когда метрики производительности, такие как время отклика или объём транзакции, выходят за установленный порог.
- **Инциденты безопасности**: в случае обнаружения событий, связанных с безопасностью, таких как провалы авторизации или попытки неавторизованного доступа.

---

# Средства мониторинга

- Nagios (1999)
- Zabbix (2001)
- Pandora FMS (2004)
- Prometheus (2012, Go) – система приложений для мониторинга на основе временных рядов
- Carbon + Graphite (2017, python)
- VictoriaMetrics (2018, Go) – полностью совместимая замена с сохранением всех интерфейсов Prometheus
...

---

# Nagios

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

![bg left:50% 90%](./images/nagos.png)

- Одна из первых популярных систем мониторинга.
- Ныне по всем параметрам уступает Zabbix  и  Pandora FMS.
- [Nagios](https://pandorafms.com/blog/ru/10-причин-по-которым-не-следует-устанав/) с нами уже почти четверть века. Это хорошо, но это также влечет за собой некоторые ограничения.

---

# Zabbix

<style scoped>
h1 {
    font-size: 0.9rem;
}
p {
    font-size: 0.7rem;
}
li {
    font-size: 0.7rem;
}
</style>

![bg right:50% 90%](./images/zabbix.png)

- Push-режим с агентами.
- Узлы сети.
- Триггеры.
- Шаблоны.

![height:150px center](./images/zabbix-scheme.svg)

P.S. Zabbix приостановил деятельность в РФ с 07 мар 2022. [Zabbix](https://github.com/zabbix/zabbix) выпущен по лицензии GPL, таким образом, является бесплатным для коммерческого и некоммерческого использования.

---

# Prometheus

- Prometheus является базой данных временных рядов (TSDB).
- Язык запросов PromQL.
- Pull-режим работы – Prometheus сам опрашивает exporter-ы для сбора метрик.
- В случае недоступности/зависания сервера метрики за этот промежуток времени будут утеряны (дырки на графиках).
- Плохо работает в кластере, нужно либо иметь независимые ноды, либо настраивать [Thanos](https://thanos.io/).

---

# Prometheus-стек

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

**Exporter** - любая программа, которая отдает метрики; **Prometheus** - сердце системы, собирает метрики, TSDB; **Alertmanager** - система управления оповещениями; **Grafana** - система построения графиков по метрикам.

![height:400px center](./images/promstack.png)

---

# VictoriaMetrics

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
</style>

- Drop-in replacement (полностью совместимая замена с сохранением всех интерфейсов) для Prometheus.
- Доработанный язык запросов PromQL.
- Имеет другой подход к сжатию метрик, что позволяет [до 10 раз уменьшить объем хранимых метрик за тот же промежуток времени](https://last9.io/blog/prometheus-vs-victoriametrics/).
- Push/Pull режимы работы.
- Кластеризация из коробки.
- В разработке принимают участие некогда проживавшие на территории РФ разработчики.

---

# Средства логирования (1)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- stderr – поток вывода "ошибок", UNIX
- syslog (sys[k]logd, 1980) – заложил основы протокола syslog
- syslog-ng (1998) – расширение фильтрами, TCP и TLS
- rsyslog (2004) – расширение RELP, buffer, модули
- Loggly (2009), Splunk, облачные и платные решения …
- Apache Flume (2009) – как часть Hadoop
- journald (2010) - как часть проекта system
- ELK/EFK (2010, JVM) – Elasticsearch, Logstash (Filebeat), Kibana
- Fluentd (2011, Ruby) – децентрализованный сбор данных
- Graylog2 (2015) – менеджер логов из разных источников

---

# Средства логирования (2)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- Grafana Loki (2018) – система агрегации логов, проще
- [MONQ (2019)](https://monq.ru/) – российская разработка основы под AIOps ([искусственный интеллект для ИТ-операций](https://en.wikipedia.org/wiki/Artificial_Intelligence_for_IT_Operations))
...

---

# ElasticSearch + Logstash + Kibana (ELK)

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 1rem;
}
li {
    font-size: 1rem;
}
</style>

ElasticSearch, Logstash и Kibana изначально разрабатывались как продукты с открытым исходным кодом и развивались отдельно друг от друга, но в 2015  году они объединились под брендом Elastic и стали позиционироваться как единый продукт - ELK-стек.

Elastic изменила лицензию Elasticsearch и Kibana с полностью открытой лицензии Apache 2 на проприетарную двойную лицензию. Стеком ELK также сложно управлять в масштабе.

---

# Иллюстрация ELK-стека

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![height:520px center](./images/elk-stack.jpeg)

---

# [Альтернативы ELK-стеку с открытым исходным кодом](https://signoz.io/blog/elk-alternatives/#signoz-open-source)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- [**SigNoz**](https://signoz.io/) -  это полнофункциональное приложение с открытым исходным кодом, которое обеспечивает сбор журналов и аналитику. SigNoz использует столбчатую базу данных [ClickHouse](https://clickhouse.com/) для хранения журналов, которая очень эффективна при приеме и хранении данных журналов.
- [**Graylog**](https://graylog.org/) -  это платформа централизованного управления журналами, которая предоставляет два решения - управление журналами и управление информационными событиями безопасности. Graylog также предоставляет версию с открытым исходным кодом, называемую [Graylog Open](https://graylog.org/products/source-available/) (**доступ заблокирован из РФ**).
- [**Grafana Loki**](https://grafana.com/oss/loki/) — это система для сбора, хранения и анализа логов, которая использует методы индексации на основе меток и предоставляет возможности запросов и визуализации логов облачных серверов через веб-интерфейс Grafana.

---

# Grafana Loki

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- В отличие от других подобных систем Loki основан на идее индексировать только метаданные логов — labels (так же, как и в Prometheus), a сами логи сжимать рядом в отдельные блоки.
- Таким образом получаем небольшой индекс и можем искать данные, фильтруя их по времени и по проиндексированным полям, затем сканируя оставшееся регулярными выражениями или поиском подстроки.
- Требует меньше памяти, проще в обращении.
- Сложные запросы могут работать дольше.
- Писать сложные запросы – сложнее.
- Еще немного сыроват, но активно развивается.
- Легко интегрируется с другими решениями.

---

# [Monq](https://docs.monq.ru/docs/reference/structure)

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![height:520px center](./images/monq.png)

---

А теперь представьте, что вам придется разбираться с каждым инструментом и его собственным API для того, чтобы обеспечить наблюдаемость системы.

![height:450px center](./images/cat-mem.jpg)

---

# OpenTelemetry

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

[OpenTelemetry](https://opentelemetry.io/) (OTel) — это кроссплатформенный стандарт для сбора и создания данных телеметрии. OpenTelemetry включает:

- **API** для библиотек, используемых **для записи данных телеметрии** в виде кода.
- **API**, которые разработчики приложений используют **для настройки** того, какая часть записанных данных будет отправлена по сети, где она будет отправлена, а также как она может быть отфильтрована, буферирована, обогащена и преобразована.
- **Семантические соглашения** предоставляют рекомендации по именованию и содержимому данных телеметрии. Важно для приложений, которые создают данные телеметрии и средства, которые получают данные, чтобы договориться о различных типах данных и о том, какие виды данных полезны, чтобы средства могли обеспечить эффективный анализ.

---

<style scoped>
li {
    font-size: 0.75rem;
}
</style>

- **Интерфейс для экспортеров**. Экспортеры — это подключаемые модули, которые позволяют передавать данные телеметрии в определенных форматах в разные серверные серверы телеметрии.
- **[Протокол проводной передачи OTLP](https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/README.md)** — это нейтральный сетевой протокол поставщика для передачи данных телеметрии. Некоторые средства и поставщики поддерживают этот протокол в дополнение к существующим собственным протоколам, которые они могут иметь.

![bg right:50% 95%](./images/opentelemetry.png)

---

# Использованные источники

<style scoped>
h1 {
    font-size: 1rem;
}
li {
    font-size: 0.8rem;
}
</style>

1. [Наблюдаемость .NET с помощью OpenTelemetry - .NET](https://learn.microsoft.com/ru-ru/dotnet/core/diagnostics/observability-with-otel)
2. [Основные аспекты наблюдаемости систем](https://habr.com/ru/companies/ruvds/articles/727072/)
3. [Observability: как наблюдать за системой?](https://agilemindset.ru/observability-как-наблюдать-за-системой/)
4. [Практическое руководство по реализации Observability в DevOps](https://habr.com/ru/companies/ruvds/articles/701034/)
5. [Как попробовать ELK-стек за один вечер и наконец-то перестать grep'ать логи](https://habr.com/ru/articles/671344/)
6. [Система мониторинга Zabbix для начинающих](https://eternalhost.net/blog/sistemnoe-administrirovanie/zabbix-chto-eto?ysclid=lnh1y5q8b2651884237)
7. [Распределенное логирование или как дебажить, когда микросервисы](https://www.tune-it.ru/web/egoshin/blog/-/blogs/raspredelennoe-logirovanie-ili-kak-debazit-kogda-mikroservisy)
8. [Microservices Monitoring: Challenges, Metrics, and Tips for Success](https://lumigo.io/microservices-monitoring/)
9. [Мониторинг микросервисных приложений: взгляд SRE](https://habr.com/ru/companies/itsumma/articles/505976/)
10. [Просто о сложном: трассировки в микросервисах](https://habr.com/ru/companies/simbirsoft/articles/740152/)

---

<style scoped>
h1 {
    font-size: 1rem;
}
li {
    font-size: 0.8rem;
}
</style>

11. [What Is OpenTelemetry? Concepts, Architecture, and a Tutorial](https://lumigo.io/opentelemetry/)
12. [Getting Started with OpenTelemetry Python](https://opentelemetry-python-kinvolk.readthedocs.io/en/latest/getting-started.html)
13. [OpenTelemetry Collector: A Friendly Guide for Devs](https://dev.to/aspecto/opentelemetry-collector-a-friendly-guide-for-devs-41jh)
14. [OpenTelemetry на практике](https://habr.com/ru/companies/ru_mts/articles/537892/)
15. [OpenTelemetry](https://opentelemetry.io/)
16. [Павел Труханов. Мониторинг Postgres по USE и RED. Расшифровка с PGConf.Russia](https://habr.com/ru/articles/514180/)
17. [Prometheus vs. VictoriaMetrics (VM)](https://last9.io/blog/prometheus-vs-victoriametrics/)
18. [Jaeger для трассировки в микросервисной архитектуре](https://habr.com/ru/companies/yandex_praktikum/articles/729906/)
19. [Zabbix vs Nagios vs Pandora FMS: подробное сравнение](https://pandorafms.com/blog/ru/zabbix-vs-nagios-vs-pandorafms-a-comparison-in-depth/)

---

# Вопросы?

<style scoped>
p {
  text-align: center;
}
</style>

![height:430px center](../images/questions.jpg)

**If not, just clap your hands!**
